feat(auth): use 'Token' as authentication header #7894
Conversation
|
前端部分的PR：AlistGo/alist-web#242 |
|
建议header名用 |
| @@ -8,6 +8,7 @@ import ( | |||
| type Addition struct { | |||
| driver.RootPath | |||
| Address string `json:"url" required:"true"` | |||
| AuthHeader string `json:"auth_header" type:"select" options:"Authorization,X-Token" default:"X-Token"` | |||
There was a problem hiding this comment.
这里的修改需要在init函数中判断下AuthHeader ，如果为空则设置默认值
There was a problem hiding this comment.
感谢建议！是指在此处修改代码吗？
// drivers/alist_v3/meta.go
func init() {
op.RegisterDriver(func() driver.Driver {
- return &AListV3{}
+ d := &AListV3{}
+ if d.Addition.AuthHeader == "" {
+ d.Addition.AuthHeader = "X-Token"
+ }
+ return d
})
}
既然 AuthHeader 已经在结构体中设置了 default:"X-Token"，为什么还需要在 init 函数中再次判断是否为空呢？是否为了避免用户未选择或者其他特殊情况？
希望能得到您的进一步解释，非常感谢！
|
我理解你想要同时使用 Basic Auth 进行认证的需求。然而同时使用多种认证方式本身就是不建议的，也是一个很少用到的场景。在这种情况下你应该在进行 Baisc Auth 认证的网关上修改使用的请求头，而不是修改 alist 反向兼容。 Authorization 是 HTTP 协议中定义的一个用于认证的标准头字段（RFC 7235），使用 X-Token 头是不符合规范的，这可能会使新加入的开发者感到困惑。因此我认为把默认请求头修改为 X-Token 是不合适的。 |
感谢指出问题！ Alist 作为一个可 self-hosted 的服务，在某些情况下需要隐藏服务器特征。Basic Auth可以很好的满足这一点，而不仅仅是用于身份验证。 我对 Nginx 的了解不深，据我所知，Nginx 似乎并没有提供一个直接的方法来修改 Authorization 头。如果有可行的解决方案，欢迎指正。 X-Token 头确实不符合标准规范，但我不知道是否有更合适的方案。似乎 X-Auth-Token 和 X-Access-Token 也是比较常见的选择，但它们同样不符合标准。如果你有更好的建议，也欢迎分享。 |
Nginx 不能方便地更换 Header 可以认为是 Nginx 的不足，我们应该去改进 Nginx。而且我想在 Nginx 中应该可以通过，例如 auth_request、临时使用变量存储原头进行置换、使用 lua 脚本，选取这三种中的一个可以实现你需要的修改使用的请求头的需求，而不是无法修改。或者你也可以寻求其他的网关。 对于你说的信息安全的问题，我深感认可。然而实际上，basic auth 在安全性方面不是最佳方案，在密码较弱的情况下无法提供足够的保护甚至可能导致密码泄露。你可以使用一些更现代化的认证方式比如建立 OIDC Server 然后使用 oauth2proxy 作为网关，oauth2proxy 会使用 cookie 存储认证信息而避免冲突。或者你也可以直接使用 tailscale、zerotier 等加密的虚拟私有网络来直接避免暴露到互联网。 |
感谢提供建议！ 我理解的是basic auth与alist存在命名冲突。basic auth与alist都使用Authorization头来实现鉴权，而Authorization键只能存一个值。此时无论Nginx怎么修改，也无法正确的传递两个请求头（？ Authorization作为basic auth的头部，似乎是RFC 7617规范的一部分，看起来也不是那么容易修改。 在GPT的帮助下，我曾尝试过临时使用变量存储原头进行置换和auth_request两种方式，但工作都不符合预期，因此只能出此下策修改alist的代码了😂 |
|
之前没了解过oauth2proxy，简单看了一下，感觉也是不错的解决方案，将来可以试试看（） |
我似乎引用了错误的文档，我应该引用的是 RFC 7235 section-4.2，RFC 7617 是专门描述 Basic Auth 的。除此之外，例如 RFC 7235 还提到 Proxy-Authorization 可以用于代理服务器鉴权、RFC 6750 还提到 Bearer Token 也应放在 Authorization 头中。但这些都不重要，互相引经据典钻一个牛角尖没有意义。我前几条回复的主要内容是在告诉你，无论你使用什么网关，进行什么鉴权，如何处理鉴权，是否会破坏原应用，是否支持以某种方式处理以逗号或分号分隔的头，以及你是否能通过你的网关达成某些需求，都是添加第二层鉴权的你和你的第二层代理网关的问题。Alist 不应为此负责，而特意改到不规范的 Header 上。 这样让人反复表达同一个观点很令人不悦，我引用文档以及提出其他建议是希望你能够理解并认同上述内容，并为你提供一些额外的帮助，而不是希望讨论你的网关好不好改或者 oauth2proxy 好不好用，请不要这样做。 |
首先，对造成的困扰表示歉意。由于我本身并非专业运维，可能在描述状况时显得啰嗦和找不到重点，带来了不必要的麻烦，我再次诚挚道歉。 无论如何，take it easy，这只是一个普通的技术探讨，没有必要太过严肃😂非常感谢你和xhofe的耐心交流与指导，也希望将来alist可以越来越好！ |
fix #3829
验证头部可以从‘Authorization’和‘Token’中二选一，避免与basic auth的冲突